Cumulative content of Working Group Meetings in 2025

Date: 11/03/2025  
Participants: Victorio Bentivogli, Paul Donohoe, Natalie Muric
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • Discuss new Github Issues related to eForms.

Discussions

Issue #754 was discussed:

  • The problem with the ticket is that apparently the ND-ModificationSection is repeatable.

  • The Modification Justification Vocabulary was consulted.

gI4jisM+XWIAAAAASUVORK5CYII=

  • A possible solution would be to extend the cardinality for the predicate (referring to Modified Notice Part Reference).

  • A use case was given: When the publications office changed name to OP, all the contracts had to be amended.

    • Based on that, each contract will have a single epo-not:ContractModificationNotice.

  • Predicate’s epo:relatesToEFormSectionIdentifier linking epo-con:ContractModificationInformation to adms:Identifier. cardinality was changed from [0..1] to [0..*].

4AODDhxrvygAAAABJRU5ErkJggg==

  • Issue #758 was discussed:

    • A Contract always mentions Lots not LotGroups.

    • Are there actual notices with Groups of Lots? just a few but most were not done correctly.

    • It makes sense to have a Tender for a group of lots.

    • A predicate epo:concernsLotGroup connecting epo:ContractLotCompletionInformation with epo:LotGroup was added.

    • Predicate epo:describesLotCompletion was renamed epo:concernsLot.

4PGmvzC3eLjYAAAAAASUVORK5CYII=

  • Issue #755 was discussed:

    • Both OPT-050-Lot and OPT-050-Part fields describe a status saying if the document is in an Official Language or not.

    • A solution to this would be to infer the value of this field by using the corresponding BT-708-Lot/Part and BT-737-Lot/Part fields.

    • Another problem is that since only a URL for procurement documents is provided, this URL may point to one or many procurement documents, resulting in many instances of access term.

    • Issue #732 was referenced. In that ticket it was mentioned that 708 and 737 are mutually exclusive, proving that indeed the OPT-050-Lot and OPT-050-Part values can be inferred by BT-708-Lot/Part and BT-737-Lot/Part fields. Although there is a mistake in the mappings for these fields as they go through a procurement document.

x+TiLaQBQ5tCwAAAABJRU5ErkJggg==

  • It was discussed whether that attribute epo:isProcurementDocumentRestricted of class epo:AccessTerm is needed, because it can be inferred from the Ontology.

    • It was decided that the attribute should be kept because it is mandatory for the standard forms.

    • It was also mentioned that there should not be a mapping for BT-14 in eForms since it can be inferred.

Working Group Meeting

Date: 11/03/2025  
Participants: Natalie Muric, Sellitto Giovanni Paolo
Model editor: Achilles Dougalis
Note editor: Grzegorz Kostkowski

Agenda

  • Reviewing and refining ORSD for eAwarding.

  • Questions about selected GitHub tickets. Discussions

Discussions

  • A question was raised regarding outstanding GitHub issues that were to be prepared by the mappings team. It was clarified that the tickets had not yet been prepared.

  • The activities description for eAwarding ORSD was discussed.

    • It was clarified that the Dynamic Purchase System must be completed before the Call for Tender.

    • It was confirmed that the Award Notification is related to a Dynamic Purchase System only if an individual is awarded a contract within the DPS.

    • It was determined that the Award Notification does not belong to the eAwarding module.

    • It was noted that there is no suitable location for the DPS within the current structure.

    • It was concluded that the scope of eEvaluation, as described in the ORSD, contained activities that do not belong to the eAwarding phase.

    • A decision was made to transfer three transactions to a newly established eQualification module, which was extracted from eAwarding. These transactions include Tenderer Qualification Request, Tenderer Qualification Receipt, and Tenderer Qualification Response.

  • The participants worked on the ORSD for eQualification module.

    • A new ORSD document was created for the eQualification module based on the one for eAwarding.

    • A precise definition of eQualification was formulated, capturing its scope, which pertains to DPS and requalification systems for works.

    • The Economic Operator role was added in addition to the roles previously defined for eAwarding.

    • The distinction between DPS and the Qualification System was clarified. It was stated that the DPS is entirely electronic as for now.

    • An additional distinction was made by explaining that the Qualification System is limited in time, whereas the DPS is not.

    • The definitions of QualificationApplicationRequest and QualificationApplicationResponse were reviewed in UBL documentation. It was noted that, in UBL, the response originates from the Economic Operator, whereas the request is sent by the Buyer.

    • An explanation was provided regarding the receipt, which is a document that contains only a yes or no response.

    • A reference was made to the Directive 24, which states that the Tender Qualification Submission for DPS is considered a request to participate and is submitted by a candidate.

    • A correspondence was established between source definitions in PEPPOL and existing ePO classes to identify any missing components. It was concluded that all necessary concepts had already been modelled but some require renaming.

+PwCiawxSQSyNAAAAAElFTkSuQmCC

  • It was determined that the Call for Competition corresponds to the CompetitionNotice and appears to already be covered.

jO62gDR2kioAAAAASUVORK5CYII=

  • The use cases and natural language statements that were initially created for eAwarding were transferred to the ORSD for eQualification.

  • The eAwarding use cases and natural language statements were revised.

    • It was noted that an award decision is rarely published on the Buyer’s website and is therefore not always accessible to the Tenderer.

    • It was clarified that the Award Decision may be linked to Award Outcomes, but not to tenders.

    • It was clarified that the Award Decision is not linked to a Lot.

    • The statement regarding the standstill period was refined. It was originally stated that the standstill period lasts for 30 days, but it was adjusted to specify that the period lasts for one month.

      • It was communicated that the organization of tickets on the ePO 5.0.0 issues board had been modified, and some tickets had been categorized as low-hanging fruit.

      • Selected GitHub tickets were reviewed. Out of nine planned tasks, three were discussed, and a decision was reached for one of them.

  • The possibility of releasing a patch was discussed regarding ticket #476. It was noted that the ticket does not clearly specify the nature of the bug. A question was raised regarding why the ticket is included in the scope of version 5.0.0.

  • Ticket #711 was reviewed. It was noted that a decision had already been made during a past meeting.

  • Ticket #374 was analysed. It was stated that the issue is not of concern if it is harmless. Nonetheless, a suggestion was made to remove the attributes mentioned in the ticket if they do not serve a specific use case. A decision was made to remove these attributes, and the decision was documented in the ticket.

Action Points

To Rename epo-awa:TendererQualificationSubmision

Yuljs2kdYF4td+5qti8WufYR1sdi1r9m6WOzaR1gXi137mq2Lxa59hHWx2LWv1qqt+RYTiYTdbq9UKpADyw+dOalrf1brYrFrX78VCoXt7e3ruV3r2jusi8WufW2mhcngEkLsfHBwcHZ2ZjKZpqemQ6HQ0dFROBwuFtDbfbvRdNfeZf8fD5GeLEmLEGsAAAAASUVORK5CYII=

Working Group Meeting

Date: 06/03/2025
Participants: Victorio Bentivogli, Paul Donohoe, Natalie Muric, Pietro Palermo, Cristian Vasquez
Model editor:  Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • GitHub issue fixing for “aux: mapping” label.

Discussions

  • “aux: mapping” label

    • #738 ticket was discussed :

      • BT-684-Lot IPI regulation was discussed. That indicator is forbidden for contract notices. They are only part for result notices, 29, 30 and 32-37. It was discussed that the indicator is not needed in ePO and the ticket was closed.

    • #745 ticket was discussed, and closed.

    • #712 ticket (unpublished fields) was discussed.

      • Some changes will be done by eForms SDK 1.15 regarding concepts.

        • They will do a new section of unpublished fields at the beginning of the xml.

        • In ePO we should extend the range of ePO maskable concepts.

      • For now (regarding SDK 1.8-1.13), the current solution is satisfactory.

    • #529 ticket was discussed (Time Ontology, epo:Period)

      • It was discussed that the ePO will adopt the Time Ontology as seen in the diagram below

B3w1hqquBJQJAAAAAElFTkSuQmCC

  • TC440 Order data model latest updates were discussed Specifically it was asked that the ePO team:

    • Goes through the old Order data model and make sure that ePO covers it.

    • Fills in Order change Order response, Order agreement tabs.

    • There will be a different annex for ePO concept mappings. There will be a deadline by April.

  • During the discussion, it was mentioned that the Quotation concept is not different from a Catalogue.

Action Points

  • Account for all open issues with milestone ePO 5.0.0

    • Also suggest which open issues should go to epo 5.1.0 or 6.0.0.

Working Group Meeting

Date: 04/03/2025
Participants: Victorio Bentivogli, Veit Jahns, Natalie Muric
Model editor:  Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • Pre-award Catalogue

  • eAwarding

  • eRequest

Discussions

Further Clarifications for modeling a Pre-award Catalogue were given:

  • epo-cat:ProductSpecification was moved on the level of epo:Document and not epo-cat:PostAwardDocument.

  • At-voc-new:document-type was moved to the level of epo:Document.

sXxaHAAAAAElFTkSuQmCC

  • Predicate epo-cat:hasDocumentType was renamed as epo:documentUsedInPublicProcurement

rk+gblVSJrAAAAABJRU5ErkJggg==

  • Attribute epo-cat:hasHazardousClass of class epo-cat:AbstractItem was removed

  • Predicate Epo-cat:hasHazardousClassID was created with domain epo-cat:AbstractItem and range adms:Identifier.

HO3w+fWvAAAAAElFTkSuQmCC

  • Attribute epo-cat:hasClassificationCode [0..1] was added at the epo-cat:ItemProperty.

  • Predicate adms:identifier with domain epo-cat:ItemProperty and range adms:Identifier was added.

  • As seen in the diagram below,Class Epo:ProcurementDocumentsProvisionLine was created.

tyWPe2fttealhrxMaAhS0O71YADxsesQMubo7AfBbtv8P+L+BRnUeKsgAAAAASUVORK5CYII=

  • PreAwardCatalogueRequestLine was added.

Action Points

  • Create Github issues for 5.0.0:

  • Close 623 github issue.

  • to Investigate the reasoning behind the use of “ procurement documents provision” naming and not ”call for tenders”.

Working Group Meeting

Date: 27/02/2025
Participants: Victorio Bentivogli, Pietro, Dragos Stoica,
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • eAwarding

  • eRequest

  • GitHub issue fixing for “aux: mapping” label

Discussions

  • During the meeting, the 'request for offer' diagram was discussed, and expanded.

wdWE72qoyCPUAAAAABJRU5ErkJggg==

  • Regarding the above diagram, the following notes were made:

    • Should we use pre-award Catalogue, post-award Catalogue or both?

    • In UBL, we have a reference to the Contract.

    • Proposal to move the attribute epo:hasAdditionalInformation of Class epo-req:RequestForOffer at the level of the epo:Document since there are other documents that might re-use it; it also exists at the level of the epo:Notice, which is a type of epo:Document.

    • in UBL , RequestForQuotation, the DestinationCountry is at the level of the document.

    • can the delivery information be at the line level as well?

  • Regarding GitHub issue fixing for “aux: mapping” label:

Working Group Meeting

Date: 25/02/2025
Participants: Victorio Bentivogli, Natalie Muric, Dragos Stoica,
Model editor:  Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • eAwarding

  • eRequest

Discussions

  • During the meeting, the eRequest ORSD was developed.

    • The introduction was expanded: “In the procurement domain, eRequest represents a document created by the Buyer to request an offer for goods and services from a Contractor within a Framework Agreement and direct awards for procurements below threshold (small scale procurement).”

    • The Roles Involved were expanded:

      • Buyer

      • Contractor

      • Offer Issuer

    • The Activity description was expanded:

      • The Buyer sends a Request for Offer to the Contractor.

      • The Contractor receives the Request for Offer and analyses it.

      • The Offer Issuer issues and sends the Offer to the Buyer.

      • The Buyer receives the Offer and analyses it.

        • If the Offer is accepted, the Buyer writes the Contract/Order based on the Offer.

        • If the Offer is not accepted, the Buyer may ask for modifications of the Request for Offer and re-start the process.

  • During the meeting, the eAwarding ORSD was further developed.

    • The DPS was further explained by sharing this document.

    • The Description was divided into two segments: Awarding Notification and Dynamic Purchase System.

    • For the Dynamic Purchase System the following description was added: “Dynamic Purchase System

      1. The Buyer creates a Call For Competition.

      2. The Unique Responsible of the Procurement *ensures *the evidence for the Participation Conditions and the Qualification Criteria are fulfilled by Candidates proposed for Qualification.

      3. If the evidence is good, the Qualification Response is *sent *by the Unique Responsible of the Procurement to the Candidate mentioning he is accepted on the Candidate List.

      4. If the evidence is not good, the Qualification Response is *sent *by the Unique Responsible of the Procurement to the Candidate mentioning he is not accepted on the Candidate List. “

      5. A Call for Tender is created.

  • The Award Decision Notification diagram for the eAwarding module was presented and expanded. By the end of the WGM the diagram looked like this:

Xd3nvxYAAAAAAADw14YAAAAAAAC4RxAAAAAAAAD3CAIAAAAAAOAe+T9C4a4MqDrpKwAAAABJRU5ErkJggg==

  • In the above diagram epo-awa:AwardDecisionNotification was defined.

  • AwardDecision Attribute hasAdditionalNonAwardJustification became hasAwardJustification.

    • Definition was updated as follows: "Description of the reason behind an award or non-award of a given Tender.Additional information: This is generally used when the non award justification code is set to "Other" and when the Lot is awarded. It may highlight the justification of the non-award of a Tender with regard to awarded Tenders."

Action Points

Working Group Meeting

Date: 20/02/2025
Participants: Victorio Bentivogli, Natalie Muric, Dragos Stoica. Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • ESPD

  • eRequest

  • Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

Discussions

The ESPD #413 ticket was discussed again:

  • It was mentioned that information such as the one mentioned in the ticket should be Additional Information.

  • It was decided this should not be of class cccev:Evidence, as it is currently modeled and it should be modeled differently.

  • There is a need for a superclass other than Evidence.

Information on the eRequest concept was given:

  • It is a request for an offer in a Framework agreement, and its response. It is also related with mini-competition.

#691 was discussed:

Concerning the review diagram:

  • Class epo:ReviewObject was removed.

  • Attribute epo:hasNumberOfReviewRequests of class epo:ReviewRequest was removed.

  • Attribute epo:hasRequestDate of class epo:ReviewRequest was removed.

  • Attribute epo:hasDecisionDate of class epo:ReviewDecision was removed.

XVxSWHlipzP508HXYb+TrZhqLSQMxb0WIeqsoYFEvNoNW9KGNzSvO1ku+w4BQgg0zmcHm7f9MnJafINAADwOf4Pfiay9DofS+YAAAAASUVORK5CYII=

  • Class epo:ReviewRequest became a specialization of epo:Document.

  • Class epo:ReviewDecision became a specialization of epo:Document.

  • Predicate epo:specifiesReviewRequester [0..1] with domain epo:ReviewRequest and range epo:ReviewRequester was added.

  • Predicate epo:specifiesReviewer [0..1] with domain epo:ReviewDecision and range epo:Reviewer was added.

  • Attribute epo:hasElementReference xsd:anyURI [0..*] was added to class epo:Document.

  • Attribute epo:hasNumberOfReviewRequests xsd:integer [1] was added to class epo:ReviewRequestSummary.

x+37mPe5mgmFQAAAABJRU5ErkJggg==

Concerning the completion notice relations diagram:

  • Predicate epo:announcesReviewObject [0..*] with domain epo-not:CompletionNotice and range epo:ReviewObject was removed.

BxVaz2ggl6AeAAAAAElFTkSuQmCC

  • Predicate epo:refersToReviewRequest [0..*] with domain epo-not:CompletionNotice and range epo:ReviewRequest was added.

3PY8YFIfEgAAAAAASUVORK5CYII=

Concerning the result notice relations diagram:

  • Predicate epo:announcesReviewObject [0..*] with domain epo-not:ResultNotice and range epo:ReviewObject was removed.

G4HdyAAAAABJRU5ErkJggg==

  • Predicate epo:announcesReviewRequest [0..*] with domain epo-not:ResultNotice and range epo:ReviewRequest was added.

V3Q9F4LDgAAAABJRU5ErkJggg==

Action Points

  • Create github issue for TED mappings repository informing for the changes done in this WGM regarding the review concepts.

Working Group Meeting

Date: 18/02/2025
Participants: Natalie Muric, Giovanni-Paolo Sellito
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • eAwarding discussions

Discussions

The eAwarding Ontology Requirements Specification Document (ORSD) was further developed. Specifically:

The following Roles are involved in eAwarding:

  • Unique Responsible of the Procurement – played by a Person; it is part of the Buyer’s Organization (the head of the Organisation; the person that has the final decision)

  • Buyer

  • Tenderer

  • Winner

  • Candidate

The Award Decision is based on the Evaluation report. The Unique Responsible for the Procurement either accepts the findings of the Evaluation Report, or takes another decision (in case the winner does not fulfill all the criteria for the award of the contract).

The Activity description section was written as follows:

  1. The Award Decision is written by the Unique Responsible of the Procurement.

  2. The Unique Responsible of the Procurement *ensures *the evidences for the Participation Conditions and the Qualification Criteria are fulfilled by Tenderers proposed for an Award.

    1. If the evidences are good, the Award Decision is signed by the Unique Responsible of the Procurement.

    2. If the evidences are not good the Buyer can ask for clarifications from the non-compliant Tenderer:

      1. If the clarification confirms that the evidence is good, the Award Decision is signed by the Unique Responsible of the Procurement.

      2. If the clarification confirms that the evidence is not good, the evidences of another Tenderer(s) are checked until we reach the required number of Winners

  3. The Tenderers are notified about the result through one of the following:

    1. Award Decision is* published* on the Buyer’s website

    2. Award Notification is *sent *to the Tenderers

  4. A standstill period (while the contract cannot be signed) of one month starts from the notification to allow other Tenderers to request Review.

  5. At the end of the standstill period the Contract can be signed.

  6. No later than 30 days after the conclusion of a Contract, a Result Notice must be published.

The following Use cases were added:

Use case Description Actors Flow

The Award Decision is written

The Award Decision is* written *by the Unique Responsible of the Procurement.

Unique Responsible of the Procurement

The Unique Responsible of the Procurement writes the Award Decision based on the Evaluation Report.

Participation Conditions and the Qualification Criteria are checked

The Participation Conditions and the Qualification Criteria are assessed.

Unique Responsible of the Procurement

The Unique Responsible of the Procurement ensures the Participation Conditions and the Qualification Criteria are fulfilled by checking the evidences referenced/written in the ESPD.

Clarifications from the non-compliant Tenderer are required

If the evidences are not good the Buyer can ask for clarifications from the non-compliant Tenderer.

Unique Responsible of the Procurement,

If the clarification confirms that the evidence is good, the Award Decision is signed by the Unique Responsible of the Procurement.

The Award Decision is signed

The Award Decision is* signed* by the Unique Responsible of the Procurement.

The Unique Responsible of the Procurement signs the Award Decision.

The Tenderers are notified about the result of the procurement.

The Award Decision is published on the Buyer’s website OR an Award Notification is sent to the Tenderers.

Buyer, Tenderer

The Tenderers are notified about the result through one of the following:

It was noted that the Qualification Response should be in another module.

Working Group Meeting

Date: 13/02/2025
Participants: Peter Borresen, Dragos Stoica
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • eFulfilment Receipt advice data model.

Discussions

ResponseStatus codelist was put at the level of AbstractContainer as seen on the diagram below:

H5Xn0ZjodhkAAAAASUVORK5CYII=

  • Further Questions regarding the fields of the Receipt advice data model were answered.

There was a further discussion with the ESPD team regarding ticket https://github.com/OP-TED/ESPD-EDM/issues/413:

ifgrKMX2H2zvDuRfsHvL8X1IeYSPsXONd414Af9bHOLW53p7aRQSBAAAZQsCAAAAHsRs1En5PC6dyqVR97c2CGurADxS+9tbTAYNAgCAsgUBAAAAH43LYbOYdAAeNS0EAADl6i9mow4AAMBHkcsk0hMRAI+aQacufW8DAMoBBAAAAAAAAABlBAIAAAAAAACAMgIBAAAAAAAAQBmBAAAAAAAAAKCMQAAAAAAAAABQRiAAAAAAAAAAKCMQAAAAAAAAAJQRCAAAAAAAAADKCAQAAAAAAAAAZQQCAAAAAAAAgDICAQAAAAAAAEAZ+YvZoAUAAAAAAACUif8PzaVVo+oY6acAAAAASUVORK5CYII=

  • Add a Github Issue about renaming that highlighted property seen in the diagram above in order to cover for the parts mentionerd in the https://github.com/OP-TED/ESPD-EDM/issues/413 depicted in the figures below. A possible name could be epo:canProvideEvidence Also the attribute coversAllSelectionCriteria should be at the level of the evidence.

wVeP3KRaHQkZgAAAABJRU5ErkJggg==
NEoAnahOUDlAJ0r066cE0InqBCWATlSJlAA6UZ2gBNCJKpESQCeqE5QAOlElUgLoRHWCEkAnqkRKAJ2oTlAC6ESVSAmgE9UJSgCdqBIpAXSiOkEJoBNVIt0NoP8vVgGQgLO74ooAAAAASUVORK5CYII=
YAAOCH4IflPIFWBgAAAAAAgBi0MgAAAAAAAMQubNBXAQAAAAAAAHjQygAAAAAAABCDVgYAAAAAAIAYtDIAAAAAAADEoJUBAAAAAAAgBq0MAAAAAAAAMWhlAAAAAAAAiEErAwAAAAAAQAxaGQAAAAAAAGLQygAAAAAAABCDVgYAAAAAAIAYtDIAAAAAAADEoJUBAAAAAAAgBq0MAAAAAAAAMWhlAAAAAAAAiEErAwAAAAAAQAxaGQAAAAAAAGIXGOsrAAAAAAAAADxoZQAAAAAAAIhBKwMAAAAAAEAMWhkAAAAAAABi0MoAAAAAAAAQg1YGAAAAAACA2P8DpCv8rdb3tWQAAAAASUVORK5CYII=
TNKnbu3LlixYrFixdv2bLlf0tyk6VLl3bdaR4MeAbxCNnW1tZwSuUbNmw48HitCLNu3bpkG4mjEUk4EolE09EJ4UgkEt0ESTgSiUTTkYQjkUgk4UgkEk1HEo5EIpGEI5FINB1JOBKJRBKORCLRdCThSCQSSTgSiUTTkYQjkUgk4UgkEk1HEo5EIpGEI5FINB1JOBKJRBKORCLRdCThSCQSSTgSiUTTkYQjkUgk4UgkEk1HEo5EIpGEI5FINB1JOBKJxL+CcIwbN2716tWNJxKJRLfB3LlzZ86cGSnmE4lE98TKlSsnTpzYRMLxzjvv9OvXb9CgQZr570Qi0f0wadKkvn373nXXXdYejecSiUT3AA4wYMAAZAAraCQKB8EhE462trYFCxbMnj27tbX174lEovvB3G9paZk5c+acOXMazyUSiW4DTGDJkiVYQSNROAgOmXAkEolEIpFIHCqScCQSiUQikWg6knAkEolEIpFoOpJwJBKJRCKRaDqScCQSiUQikWg6knAkEolEIpFoOpJwJBKJRCKRaDqScCQSiUQikWg6knAkEolEIpFoOpJwJBKJRCKRaDqScCQSiUQikWg6knAkEolEIpFoOpJwJBKJRCKRaDqScCQSiUQikWg6knAkEolEIpFoOv4PU9iXAmDDf2wAAAAASUVORK5CYII=

Action Points

  • Create a Github Issue to implement Object Line Identifier with the predicate SalesOrderLineID.

  • Add a Github Issue about renaming that highlighted property mentioned above.

Working Group Meeting

Date: 11/02/2025
Participants: Natalie Muric, Dragos Stoica
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • eAwarding ORSD

Discussions

A new definition for the epo-sub:ESPD was given according to the diagram below:

YhHDjQwf8HyKKBj3YrX28AAAAASUVORK5CYII=
iYEVMACWswAAAABJRU5ErkJggg==
8feK1wv8CGG+r2ojXfSqQZ20QwFEwxBxz7fuK3+P10AOg8b1wyWAAAAAElFTkSuQmCC

Issue #734 was updated accordingly, and epo-sub:ESPD and ePO-acc:ESPDRequest: were updated accordingly.

The WG started discussing about the ORSD for the eAwarding module.

ESPD-EDM https://github.com/OP-TED/ESPD-EDM/issues/423 and https://github.com/OP-TED/ESPD-EDM/issues/413 issues were discussed:

  • #423:

    • eForms and UBL are not aligned, ESPD is aligned with UBL.

    • A qualifying party has a codelist that describes the role. So ESPD is covered by this. 423 can thus be closed.

  • #413

    • It was discussed that although the specific field mentioned in issue #413 covers multiple lists or equivalent certificates, in the ePO there are no Lists.

    • It was mentioned that the information conveyed by that specific field is not used as an evidence for any criterion and that it should be modelled as additional information and not evidence.

Working Group Meeting

Date:30/01/2025  
Participants: Peter Borresen, Natalie Muric
Model editor: Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Alignment with PEPPOL for eFulfilment #569.

Discussion

  • Alignment with PEPPOL for eFulfilment #569.

    • Definitions and clarifications were given for specific Business Groups, and Business Terms in the Receipt Advice data model.

Action Points

  • Create a Github Issue: Harmonize all post award document classes such as despatch advise to use
    The epo:associatedWith rather than a direct link to an epo:Document.
    Also add a link from the lines to a document.

z8BM81bbOD8bgAAAABJRU5ErkJggg==
fxg9J6ikIYVjAAAAAElFTkSuQmCC
Aym7ClPzXPmo+qggYSvxVLTyi8B58A0khqRu2+wrKAAAAAElFTkSuQmCC
dNUa2Q9w4AkAAAAASUVORK5CYII=

Working Group Meeting

Date: 28/01/2025
Participants: Victorio Bentivogli, Paul Donohoe, Ioannis Fountoukidis, Yves Jordan, Natalie Muric, Giovanni-Paolo Sellito
Model editor: Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

Discussions

Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

During the meeting, definitions for the following BTs that appearon the Annex of Regulation 2023/2884:

  • BT-776 did not have any impact on the Ontology.

  • BT-810

    • Is the indicator attribute epo:isCompliantToEnergyEfficiencyDirective needed? It was decided that this indicator will not be modelled since if it is true we will have an instance of epo:EnergyEfficiencyInformation.

  • BT-811

    • Two code lists are needed:

      • Energy-efficiency-Item (already in ePO)

      • Energy-efficiency-Basis (not in ePO)

    • As a result, at-voc:energy-efficiency-basis was created, and linked to epo:EnergyEfficiencyInformation. (see diagram below).

gfJHGSczAVwAAAABJRU5ErkJggg==

  • Create two diagrams in ePO (1 for competiton and 1 for Lot-result) for epo:EnergyEfficiencyInformation class.

  • 813 and 814 are paired.

  • BT-814 :

    • It was discussed that this will be implemented with the SDK implementation., not with the Regulation 2023/2884.

    • Two predicates connecting epo:EnergyEfficiencyInformation to epo:Quantity will be epo:hasConcumptionQuantity and epo:hasSavingsQuantity.

    • The guides/gde_004_eed.pdf · main · eProcurement Group / eForms Group / Docs · GitLab Guide was consulted.

    • At the level of epo:EnergyEfficiencyInformation we will have epo:EnergyEfficiencyItem.

m+CvNcVjQo46cQQojo9v8AKFBifwwbFF4AAAAASUVORK5CYII=

Working Group Meeting

Date: 23/01/2025  
Participants: Peter Borresen, Paul Donohoe, Yves Jordan
Model editor: Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • eFulfilment meeting regarding Receipt Advice.

  • Unmappable eForms fields in PIN, CEI and T02 notice subtypeshttps://github.com/OP-TED/ePO/issues/726[#726]

  • Phttps://github.com/OP-TED/ePO/issues/529[otential problem with modelling of epo:Period ]ePO #529

  • Mapping of at-voc:timeperiod to the OWL Time Ontology ePO #681

Discussions

During the first part of the WGM, eFulfilment and specifically Receipt Advice was discussed: Definitions and clarifications were given for specific Business Groups, and Business Terms in the Receipt Advice data model.

Regarding the “Unmappable eForms fields in PIN, CEI and T02 notice subtypeshttps://github.com/OP-TED/ePO/issues/726[#726]” github issue:

  • Examples of T01 , and T02 eForms were given to the WGM.

  • Regarding the following fields: Τhey are just for T02 and are about a Tender, so they should be put in a class on the level of epo:TenderAwardOutcome. This class should be named epo:TenderAwardOutcomeInformation. Another class: epo:ContractCondition was added.

    • OPP-080-Tender: Kilometers Public Transport: Represented as a predicate to the epo:Quantity class.

    • OPP-035-Tender: Revenues Allocation of tickets sales code uses the following codelist With only one value.

    • OPP-032-Tender: Revenues Allocation: Add epo:hasTicketsSalesRevenueAllocation xsd:decimal, [0..1] attribute on epo:TenderAwardOutcomeInformation.

    • OPP-030-Tender: Contract conditions Code: uses the following codelist.

    • OPP-031-Tender: Contract Conditions Description (other than revenue allocation): epo:hasContractConditionsDescription rdf:plainLiteral. [0..1] attribute on epo:ContractConditio.n

    • OPP-033-Tender: Penalties and Rewards Code: has only one value (found here). Not going to implement.

    • OPP-034-Tender: Penalties and Rewards Description: epo:hasPenaltiesAndRewardsDescription rdf:plainLiteral [0..1] attribute to to epo:TenderAwardOutcomeInformation.

KCzrishwAAAPy6IAAAACDbpXdNkIUgAAAAvygIAAAAyHbbCZCNPj9SAADwS4AAAAAAAAAA4AGBAAAAAAAAAOABgQAAAAAAAADgAYEAAAAAAAAA4AGBAAAAAAAAAOABgQAAAAAAAADgAYEAAAAAAAAA4AGBAAAAAAAAAOABgQAAAAAAAADgAfltO7kJAAAAAAAAeCAgAAAAAAAAAHhAIAAAAAAAAAB4QCAAAAAAAAAAeED+H2itRRxdk7YeAAAAAElFTkSuQmCC

  • BT-127-Notice:No modification will happen for now.

cXfckNAKrHAJr3udMi82hMAPAfCbarVEStLmMAAAAASUVORK5CYII=

Action Points

  • Create a Github issue: For the Receipt Advice ePO diagram: To represent the action-code and reject-reasons codelists also at the level of the epo-ful:ReceiptAdvice.

mqVvqbbcXMAAAAAElFTkSuQmCC

Working Group Meeting

Date: 21/01/2025
Participants: Paul Donohoe, Yves Jordan, Dragos Stoica Model editor: Andreea Passare Note editor: Achilles Dougalis

Agenda

  • Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726

Discussions

Regarding Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726:

Regarding OPT-070-Lot:

  • An example of a Call For Expressions Of Interest document was presented (F_CEI_EN_DRAFT_2019-03-25.pdf). The ePO team used the document to create a CM diagram for Call For Expressions Of Interest.

  • The latest Notice-types.json eforms document was consulted.

  • Class epo-not:PINTransportationNotice was created as seen on the diagram below.

M78XFT1lwMAAAAAASUVORK5CYII=

  • Class epo-not:CANTransportationNotice was created as seen on the diagram below.

s5jrpLAZ8rpz6aY3x9XxWs+f8BnMPcbaw09RIAAAAASUVORK5CYII=

  • It appears that class epo-not:CallForExpressionOfInterest was already implemented in the ePO as epo-not:NoticeCEI. To discuss the removal of epo-not:CallForExpressionOfInterest in a future WGM.

Regarding OPT-071-Lot :

  • The Customer-service codelist was found and does not currently exist in ePO and will be added.

  • It was mentioned that For T02 and T01, epo:LotGroup is Forbidden

  • Class epo:QualityTargetInformation was created; it should always be linked to an epo:ContractTerm.

  • at-voc:customer-service was created on the level of epo:QualityTargetInformation. They are both mandatory.

  • Attribute epo:hasQualityTargetDescription was created.

J5sV+TexYlQAAAABJRU5ErkJggg==

Regarding Assets in a Contract: (they are all for T02):

  • OPP-020-Contract: Assets related contract extension indicator. Class epo:Asset was created.

  • OPP-021-Contract: Used asset Added dct:description [0..1] for epo:Asset.

  • OPP-022-Contract: Significance (%): Added attribute epo:hasSignificance rdf:PlainLiteral. To be further discussed as concept name may change in the future

  • OPP-023-Contract: Predominance (%): Added attribute epo:hasPredominance rdf:PlainLiteral. To be further discussed as concept name may change in the future

4OUzXEkIrXwAAAABJRU5ErkJggg==

Contract terms and other information of a Tender: These are all T02 Notices. It was decided that the WGM will work on the above fields next WGM on 23/01/2025.

OPP-040-Procedure: Main Nature - Sub Type: at-voc:transport-service was created.

a1HXP6NuObggAAAuHogAMBnpJBJpOL1a8vxBgHgOnD8XQBSOCAAAK4SCAAAAAAAAACuEQgAAAAAAAAArhEIAAAAAAAAAK4RCAAAAAAAAACuEQgAAAAAAAAArhEIAAAAAAAAAK4RCAAAAAAAAACuEQgAAAAAAAAArhEIAAAAAAAAAK4RCAAAAAAAAACukf8Pzg4zhbqF9dAAAAAASUVORK5CYII=

Action Points

Working Group Meeting

Date: 16/01/2025  
Participants: Peter Borresen, Paul Donohoe, Yves Jordan, Natalie Muric, Dragos Stoica,
Model editor:  Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Continue working on Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726

  • Alignment with PEPPOL for eFulfilment #569.

  • Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

  • Potential problem with modelling of epo:Period #529

  • Mapping of at-voc:timeperiod to the OWL Time Ontology #681

Discussions

Regarding the alignment with PEPPOL for eFulfilment #569, it was decided that the alignment between PEPPOL business term requirements and ePO eFulfilment module will continue with the Receipt Advice Data model.

Regarding the new BTs described in Regulation 2023/2884 to ePO concepts.https://github.com/OP-TED/ePO/issues/691[#691:]

  • BT-749: It was discussed that although BT-749 was removed from the regulation, no removal of an ePO concept was needed.

  • BT-681: An attribute for epo:ProcurementElement was added for this. epo:appliesForeignSubsidiesRegulation xsd:boolean[0..1]

aD+H80jDfNt6R55AAAAAElFTkSuQmCC
r83XUG1MDSgAAAABJRU5ErkJggg==

  • A use-case is required to find out in what procurement phase should this codelist be used. This will be done in the future as part of describing the Procurement Process. A link to the Digigrow guide on how to use this codelist was provided: https://code.europa.eu/eproc/eforms/docs/-/blob/main/guides/gde_001_fsr.md?ref_type=heads

  • BT-684: It was decided that this BT will not be implemented for now.

  • BT-681 : Should points to epo:LotAwardOutcome. .

  • BT-685 is for the Tender. There is currently no codelist for this. It should go directly to the epo:LotAwardOutcome class. (via the epo:InternationalProcurementInstrumentMeasuresInformation Class seen in the diagram below)

  • BT-686 : Attribute epo:hasNumberOfTendersConcerned as seen in the diagram below.

  • BT-687 : at-voc:international-procurement-instrument-application As seen in the diagram below.

  • BT-688 :Attribute epo:hasPublicInterestExceptionJustification as seen in the diagram below.

  • The International Procurement Instrument Application vocabulary was consulted. It was mentioned that the Digigrow guide (link above) better explains the above mentioned BTs.

QAAAAASUVORK5CYII=

The epo:InternationalProcurementInstrumentMeasuresInformation Class

  • It is important to note that these IPIs are for third world countries or Tenders that have third country subsidiaries.

Continue working on Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726

  • Lot tenderingTerms Fields were discussed:

    • OPT-070-Lot : Class epo:CallForExpressionOfInterest is a typeOf epo:Notice.

Working Group Meeting

Date: 14/01/2025  
Participants: Paul Donohoe, Yves Jordan, Natalie Muric
Model editor:  Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726

  • Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

Discussions

Regarding #726

  • The following IDs are mandatory in UBL but not required in eForms, so there is no need to map them to ePO either for Lot or Part:

    • OPT-111

    • OPT-112

    • OPT-113

  • The following Classes were implemented: (also depicted on the diagram below) For the following fields:

    • OPT-110-Lot-FiscalLegis

    • OPT-110-Part-FiscalLegis

    • OPT-120-Lot-FiscalLegis

    • OPT-120-Part-FiscalLegis

    • OPT-130-Lot-FiscalLegis

    • OPT-130-Part-FiscalLegis

    • epo:LegislativeDocumentation

    • epo:FiscalLegalDocumentation

    • epo:EnvironmentalLegalDocumentation

    • epo:EmploymentLegalDocumentation

    • epo:Class epo:Documentation was created that is a generalisation of the above Documentation classes.

    • Predicate providesDocumentation was added fromTaxInformationProvider to epo:Documentation

8iFAAAAAASUVORK5CYII=

  • #691

    • ΒG-700 was mapped to epo:QualificationCriterion.

    • ΒT-806: The codelist used is in eForms (exclusion-grounds-source) and it has 3 values: epo-notice, epo-sub-espd (this might be epo-acc-espd) and epo-procurement-document. We will create 3 attributes at the level of epo:QualificationCriteria for each value:

      • epo:hasQualificationCriteriaStatedinNotice

      • epo:hasQualificationCriteriaStatedinESPDRequest

      • epo:hasQualificationCriteriaStatedinProcurementDocuments.

    • BT-821: uses the same codelist as BT-806.

    • BT-67(a), BT-77(b): epo:hasExclusionGroundType predicate connected to at-voc:exclusion-ground was added.

    • BT-748 At-voc:usage will not be used anymore. Instead we create predicates epo:doesNotRequireSelectionCriterionType epo:hasUnknownUsageOfSelectionCriterionType connected to at-voc:selection-criterion codelist. that will be used in case a specific selection criterion is not used or is not yet known.

TED Developer Docs

This website is managed by: Publications Office of the European Union

Need Help?

Follow us

Legal

About us

Other services

Discover more on europa.eu

Contact the EU

Social Media

EU institutions and bodies